Deploy a real service in e2e, and cover the eight commands that needed one - #178

Eight commands that had never been run against the API now have a happy path, because the suite can now deploy.

prisma service deployment promote   prisma service deployment stop
prisma service deployment start     prisma service deployment delete
prisma service deployment list      prisma service open
prisma service deployment show      prisma service show

The blocker was a real one, and it is gone

Every deployment verb acts on a deployment, the CLI cannot make one, and only Composer can. That is why tests/e2e-coverage.test.ts carried them as owed work with no route forward.

The management API has a route: create a deployment, PUT an artifact to the pre-signed URL it answers with, then start and promote it. e2e/deployed-service.ts does exactly that, and does the last two steps through the CLI, so service deployment start and promote are proven on the way to setting the fixture up rather than assumed.

The artifact is a real tar.gz written in process — a ustar header by hand and gzipSync — rather than a checked-in binary, so there is no opaque fixture file to rot. It is a two-file Node server, which is the smallest thing the platform will actually run.

Teardown deletes the deployment before the scratch project goes, because it has to:

Cannot delete project: active deployments exist.
Please stop and delete all deployments first.

Two claims in the backlog were wrong, and checking cost nothing

The comment said the five service domain * commands needed no deployed service. They do — service domain add on an undeployed service answers SERVICE.NO_DEPLOYMENTS. With a promoted deployment in place they get further, to a wall this repo cannot climb:

SERVICE.DOMAIN_DNS_NOT_CONFIGURED — DNS verification failed: ensure the
hostname CNAMEs to switchboard.ewr.prisma.build.

So they need a hostname whose DNS the test account owns. That is now the recorded reason, in place of a guess.

service show was the one command the old comment was right about; it has a happy path too.

What is left, and why

• service deployment rollback — needs a second promoted deployment to roll back from. The fixture can make one; making two and promoting them in order is the next thing to write.
• The five service domain * commands — the DNS record above.
• build logs — needs a build, which comes from a git push or a Console action.

Also here: the ORM family cannot run through the assembled binary

Recorded in deferred.md, found while trying to write its happy paths:

$ prisma orm init --yes --target postgres --authoring psl
# writes 9 files, then exit 5: Config is not a defineConfig result

$ prisma contract emit
# CONFIG.FILE_NOT_FOUND — The orm config section is absent

orm init scaffolds prisma-next.config.ts; the mounted family reads an orm section of prisma.config.ts. So prisma orm init followed by the command it tells you to run next cannot work. The 22 ORM commands stay excluded until that is fixed — removing the exclusion today would only turn the suite red against a broken scaffold.

A third item is recorded as unverified: a hand-written prisma.config.ts failed to load with Cannot find package 'pathe' from c12. Probably a workspace layout artifact, but if it reproduces from a packed tarball then every command that reads config is broken on install. One run of the S6 tarball check with a config file present would settle it.

Verified: lint, typecheck, build clean; 60 CLI and 34 engine test files pass; the full e2e suite passes against the live API — 10 files, 54 tests, up from 9 and 46.